1. Field of Invention
The present invention relates generally to the field of software applications used on an information network (such as a cable television network), and specifically to the management and control of various hardware and related functions within an electronic device connected to the network.
2. Description of Related Technology
Software applications are well known in the prior art. Such applications may run on literally any type of electronic device, and may be distributed across two or more locations or devices connected by a network. Often, a so-called “client/server” architecture is employed, where one or more portions of applications disposed on client or consumer premises devices (e.g., PCs, PDAs, digital set-top boxes {DSTBs}, hand-held computers, etc.) are operatively coupled and in communication with other (server) portions of the application. Such is the case in the typical hybrid fiber coax (HFC) or satellite content network, wherein user client devices (e.g., DSTBs or satellite receivers) utilize the aforementioned “client” portions of applications to communicate with their parent server portions in order to provide downstream and upstream communications and data/content transfer.
Digital TV (DTV) is an emerging technology which utilizes digitized and compressed data formats (e.g., MPEG) for content transmission, as compared to earlier analog “uncompressed” approaches (e.g., NTSC). The DTV content may be distributed across any number of different types of bearer media or networks with sufficient bandwidth, including HFC, satellite, wireless, or terrestrial. DTV standards such as the OpenCable™ Application Platform middleware specification (e.g., Version 1.0, and incipient Version 2.0) require that applications be downloaded to host devices from the bearer or broadcast network in real-time. The OCAP specification is a middleware software layer specification intended to enable the developers of interactive television services and applications to design such products so that they will run successfully on any cable television system in North America, independent of set-top or television receiver hardware or operating system software choices.
The aforementioned OpenCable project at www.opencable.com also sets forth a Host Core Functional Requirements specification which defines optional circuitry for digital video recorders (DVRs), and digital video interfaces (DVIs); see, e.g., the OpenCable Host Device Core Functional Requirements OC-SP-HOST-CFR-I13-030707 specification (now OC-SP-HOST-CFR-I14-030905 dated Sep. 5, 2003).
DVR technology provides selective recording, playback, and manipulation (e.g., storage, processing, editing, etc.) of digital format content. For example, the services offered by the Assignee hereof in conjunction with exemplary Scientific Atlanta Explorer 8000 Digital Video Recorder set top box equipment (and associated high capacity mass storage device) are representative of the state-of-the-art in this technology. This service offers, inter alia, the ability to store one or more items of content (e.g., movies or television programs) simultaneously with directly watching a second (or third) program.
Personal video recording (PVR) functionality is essentially a subset of DVR technology, wherein individual users, e.g., family members within the same household, can selectively record digital content particular to their choosing while not inhibiting other individuals from doing the same. This provides significant flexibility and enhances the user experience, since each individual can tailor their viewing as desired.
DVI technology allows, inter alia, for the seamless integration of digital TV and digital-based devices with analog devices, such as analog televisions. Accordingly, if the user possesses an analog monitor, the DVI selectively converts the otherwise digital signal to the analog domain. Accordingly, the user (and manufacturer) need not selectively tailor their equipment to a particular domain. A DVI output is an option in OpenCable compliant hardware that provides a high-definition TV (HDTV) output which includes copy protection. The aforementioned Core Functional Requirements specification details the DVI requirements, including (i) presence of a Digital (DVI-D) connector, which at a minimum supports the Single Link Transmission Minimized Differential Signaling as defined in Digital Display Working Group (DDWG) Digital Visual Interface (DVD revision 1.0; and (ii) that the DVI interface on the HD Host must employ the HDCP encryption system, as defined in the HDCP System specification.
Increasingly, consumer premises equipment (CPE) and other client devices are being equipped with DVR/PVR and DVI technology. This equipment may be leased from the content/network operator, or alternatively purchased “retail” from a third party manufacturer. Clearly, it is desired to have software applications distributed by the network operator (or third-party content provider) be universally compatible with the hardware/software environments of these CPE, thereby avoiding situations where a downloaded application does not function properly which greatly adds to user frustration.
Moreover, it is highly desirable to have these applications autonomously (i.e., without a requirement for significant MSO or user intervention) discover and control the various DVR, PVR, DVI, and other hardware/software options resident on any particular consumer installation. For example, in one scheme, the delivered application may be configured to operate at the level of the lowest common denominator in terms of equipment capability. However, without a “smart” capability in the application or CPE, the owner of the more capable CPE may be robbed of the opportunity to utilize the full capabilities of their CPE with the application in question. Hence, autonomous discovery and control of options on any given CPE would effectively allow an application to tailor itself (and/or its hardware environment) to obtain optimized performance, e.g., provide the user with the greatest amount of features and flexibility of usage.
Alternatively, it may be desirable to provide the MSO some degree of control over the application and its discovery of the various hardware/software options on a particular CPE installation.
Where a plurality of different hardware/software options or devices are present with a given system, a registry is typically used to manage the various functional aspects of the operation of these options. As is well known, a registry in effect comprises a repository or database of information relating to the various options. For example, in the context of computer software, the well known Windows® O/S utilizes a registry for management of various functions within the operating system.
A variety of different approaches to controlling the operation of content-based software on client devices (e.g., CPE) using registries are taught in the prior art. For example, U.S. Pat. No. 6,169,725 to Gibbs, et al. issued Jan. 2, 2001 and entitled “Apparatus and method for restoration of internal connections in a home audio/video system” discloses an apparatus and method for the management and restoration of internal connections of consumer electronic devices in a home audio/video network. Each internal connection is labeled according to its status (e.g., active or inactive) and/or condition (e.g., network compliancy). Whenever a new device is added to or an old device is removed from the network, a network reset is initiated. The devices communicate by sending messages over the home network using a generic message passing system. When new devices join the home network, they are recognized and added to a global name database (registry). The registry holds information about their characteristics and provides a reference to a handler for that device. Other devices and services are able to query the registry to locate a device and then using the handler, can interact with the device.
U.S. Pat. No. 6,233,611 to Ludtke, et al. issued May 15, 2001 and entitled “Media manager for controlling autonomous media devices within a network environment and managing the flow and format of data between the devices” discloses a media manager providing data flow management and other services for client applications on devices coupled together within a network, such as via an IEEE 1394-1995 serial bus network. A device control module is generated for each available device for providing an abstraction for all of the capabilities and requirements of the device including the appropriate control protocol, physical connections and connection capabilities for the device. The module also provides network enumeration and registry searching capabilities for client applications to find available services, physical devices and virtual devices. The service registry includes a reference to all addressable entities within the media manager, including a reference for each device control module (DCM), DCM Manager, data flow manager, transaction manager, data format manager, bus manager, and graphics manager. The service registry also contains a number of service modules, and a service registry database including references for all of the objects that are local to its node and at specific times references to remote objects as well.
U.S. Pat. No. 6,337,717 to Nason, et al. issued Jan. 8, 2002 and entitled “Alternate display content controller” discloses a technique for controlling a video display separately from and in addition to the content displayed on the operating system monitor. Where the display is a computer monitor, the alternate display content controller interacts with the computer utility operating system and hardware drivers (including a registry) to control allocation of display space and create and control one or more parallel graphical user interfaces adjacent the operating system desktop. An alternate display content controller may be incorporated in either hardware or software. As software, an alternate display content controller may be an application running on the computer operating system, or may include an operating system kernel of varying complexity. The alternate display content controller may also include content and operating software delivered over the Internet or any other LAN, and may also be included in a television decoder/settop box to permit two or more parallel graphical user interfaces to be displayed simultaneously. See also U.S. Pat. No. 6,630,943 to Nason, et al. issued Oct. 7, 2003 and entitled “Method and system for controlling a complementary user interface on a display surface”, and U.S. Pat. No. 6,330,010 to Nason, et al. issued Dec. 11, 2001 and entitled “Secondary user interface”.
U.S. Pat. No. 6,529,965 to Thomsen, et al. issued Mar. 4, 2003 and entitled “Method of detecting TCP/IP bindings of installed network interface cards present in a computer system” discloses a method for detecting TCP/IP bindings for Network Interface Cards (NICs) installed on Windows® operating systems with a VPN (Virtual Private Network) client present. The method parses the Windows system registry to detect TCP/IP bindings for network interface cards installed within a host computer system. In one embodiment, a DriverCheck function and a HardwareCheck function are implemented as parts of software for detecting the TCP/IP bindings for network interface cards installed on the host computer system.
U.S. Pat. No. 6,600,958 to Zondag issued Jul. 29, 2003 and entitled “Management of functionality in a consumer electronics system” discloses a communication system with a plurality of controlled stations. The functionality of each controlled station is associated with a respective abstract representation, referred to as AR. The AR provides an interface for software elements in the system to control functionality of the controlled station by means of messages exchanged with the AR via the communication network. The AR may be implemented using platform-independent code, such as Java. A registry which serves as a directory service and allows any object to locate another object on the home network is also disclosed. The disclosed functional control modules (FCMs) and other similar component entities describe devices with different levels of functionality, and the ability to manage and control other devices. Entries in the aforementioned registry relate to entire devices, each with multiple hardware resources, as opposed to individual hardware resources. The IEEE-1394 registry indicates the type of network messaging protocol that can be used to communicate various units on the network.
U.S. Pat. No. 6,625,274 to Hoffpauir, et al. issued Sep. 23, 2003 and entitled “Computer system and method for providing services to users of communication systems using service entities, interface entities, and a service bus” discloses a system for providing services and includes service entities, interface entities, and a service bus. Each service entity produces and receives events and includes at least one of a reusable macro function, an application programming interface (API) function, and a management interface function. Each service is implemented with at least one service entity. Each interface entity produces and receives events and is coupled to a communication system and communicates with the communication system using a communication protocol. The service bus couples the interface entities and the service entities and passes events between the interface entities and service entities. A software-implemented service registry is also provided which tracks the services offered by the service provider and the service entities for each different service. The service entities are implemented using functions accessed from the software-implemented library.
U.S. Patent Application Publication No. 20030121055 to Kaminski, et al. published Jun. 26, 2003 and entitled “Program position user interface for personal video recording time shift buffer” discloses a system providing information about media content stored in a storage device coupled to an interactive media services client device. A window manager is disclosed which, inter alia, maintains a user input registry in DRAM so that when a user enters a key or a command via a remote control device (or another input device such as a keyboard or mouse), the user input registry is accessed to determine which of various applications running should receive data corresponding to the input key and in which order. See also related U.S. Patent Application Publication Nos. 20030110511 to Schutte, et al. published Jun. 12, 2003 and entitled “Controlling personal video recording functions from interactive television”, U.S. Patent Application Publication No. 20030005454 to Rodriguez, et al. published Jan. 2, 2003 and entitled “System and method for archiving multiple downloaded recordable media content”, and U.S. Patent Application Publication No. 20030163811 to Luehrs published Aug. 28, 2003 and entitled “Positive parental control”.
The recently proposed Home Audio Video Interoperability (HAVi) specification is a consumer electronics (CE) industry standard design to permit digital audio and video devices that conform to this standard, regardless of manufacturer, to interoperate when connected via a network in the consumer's home. The HAVi standard uses the digital IEEE-1394 network standard for data transfer between devices and the 1394 A/VC protocols for device control.
The HAVi standard focuses on the transfer and processing (for example, recording and playback) of digital content between networked devices. HAVi-compliant devices will include not only familiar audio and video components but also cable modems, digital set-top boxes and “smart” storage devices such as personal video recorders (PVRs). Compliance with the HAVi standard also allows disparate brand devices to be hooked into a home network.
By employing modular software, the HAVi standard allows consumer electronics devices to identify themselves and what they can do when plugged into the host. The software functions by assigning a device control ID module to each hardware component of a system. Each system also is assigned multiple functional component modules, containing information about an individual device's capabilities, for example, whether a camcorder operates in DV format, or whether a receiver is designed to process AC3 audio.
HAVi-compliant devices automatically register their operating status, device functions and location with other components in the network. So when a host device recognizes a new component on a HAVi system, the host loads the appropriate device and functional modules, allowing users to control the target device from the host.
The HAVi Registry is a system service whose purpose is to manage a directory of software elements available within the home network. It provides an API to register and search for software elements. Within one device any local software elements can describe themselves through the Registry. If a software element wants to be contacted, it must register with the Registry. System software elements are registered so that they can be found and contacted by any software element in the network.
The Registry maintains, for each registered object, its identifier (SEID) and its attributes.
The Registry also provides a query interface which software elements can use to search for a target software element according to a set of criteria.
Each Registry contains tables describing local software elements (software elements within the same device). The logical database is viewed as the set of all these tables. Each Registry service offers the possibility to query this database.
Applications can query the Registry to find the devices and functional components available, and to obtain their software element identifiers. This allows the application to interact with the device via the device control module (DCM) and the functional component modules (FCMs). A DCM and its FCMs are obtained from a DCM code unit for the device.
DCM code units are installed by FAVs and IAVs. Installation of a code unit results in the installation of the DCM and all the associated FCMs. DCM code units can be written in Java bytecode, in which case they can be installed on any FAV device, or in some native code, in which case they can be installed only on (and by) some FAV or IAV that can execute that code.
Each object is uniquely named. No distinction is made between objects used to build system services and those used for application services. Objects make themselves known via a system wide naming service known as the Registry.
Objects in the system can query the Registry to find other objects and can use the result of that query to send messages to those objects.
The identifier assigned to an object is created by the Messaging System before an object registers. These identifiers are referred to as SEIDs—Software Element Identifiers. SEIDs are guaranteed to be unique, however the SEID assigned to an object may change as a result of reconfiguration of the home network (for example, device plug-in or removal, or re-initialization of a HAVi device).
Despite the foregoing, no suitable methodology or architecture for allowing an application running on CPE to discover and control the hardware options present on the CPE has been disclosed under the prior art. Accordingly, there is a need for improved apparatus and methods for the autonomous discovery and control of hardware options and features within these devices by such applications. These improved apparatus and methods would ideally meet these needs in a “universal” fashion; i.e., across heterogeneous hardware environments (whether retail or leased), while also providing compliance with industry standard requirements within the network.